AMD Ryzen crashes (Klonan) The long fight with the elusive Ryzen bug (more and more) seems to finally have some resolution. A few weeks ago I sent an email to AMD, filling them in on the details of the crash, and asked them if they could help us solve this. Very quickly I was put in touch with a member of their CPU engineering team, and they got to work with their investigation. After a few days, and after providing them all the information we have (log files, source code, crash dumps etc.), the cause of the issue was identified. Some other developers in the industry also had this problem and worked with AMD to fix it, so it's unlikely that the CPU bug was fixed only because of us, but we are honoured to have contributed to this. Unfortunately we do not have any technical or deep insight into where exactly the problem lay, or what the fix was, as it was somewhere between the motherboard BIOS and the Ryzen chipset drivers. So if you are running Factorio on a Ryzen system, we advise you to update your BIOS using the files and procedures found on your motherboard manufacturer's website, and update your chipset drivers to the latest version.
Factorio Nomenclature Abregado Today I want to discuss some common problems that we see in video games. Inconsistent Terminology When I asked out loud "So what is an Intermediate Product anyway?", I got a similar reaction as when someone mentions The Berlin Interpretation at a rougelike convention. So what is an Intermediate Product? Well it is a product that is used only as an ingredient for something else. No, that's not right because Science Packs are not used in any recipe. So what then, Intermediate products are just things that you can use Productivity Modules on? Perhaps they are simply items that can be found in the Intermediate Crafting menu. Then are they not Intermediate Recipes? To give another example, answer these questions: Name the action a player performs when they add an entity to the world? Name the action a player performs when they remove an entity from the world? Name the action a player performs when they add a ghost entity to the world? Name the action a robot performs when they add an entity to the world? Name the action a robot performs when they remove an entity from the world? Here are a few situations where the game displays your possible answers: A player builds. A player mines entities. Robots repair and build entities, but wait… the player places buildings and builds ghosts? But here Robots are constructing machines. Here the robots are deconstructing items! This leads into a discussion about what is an item and what are entities, and that discussion leads us into the next point... Internal nomenclature leaking out During game development it is very common to use internal names to refer to mechanics, items, or characters. It does not feel like such a big deal, and many early access games simply ignore the problem completely. I'm not going to point any fingers, but if you look you will find some examples. Oh wait, here is some from your favourite early access game! Internally, things that exist on a surface in the game are called entities. All these items are capsules internally, but only 5 of them are actually labelled as capsules. Really, these should be categorised by how players use them, and indeed there is an attempt to do so. Remotes are items used to trigger an effect, Grenades are things you throw... but why is the Poison Capsule not called a gas grenade? There are more inconsistencies but to keep this article reasonably not-short, I will let you find the others yourself (and to save something for a future FFF about Tooltips). Why change? You might be thinking that this is not a big problem. Some others might be thinking that the problem is too pervasive to bother changing. There are a few reasons why it is important, the first, and most important of which is our quality mindset; everyone on the team here wants the game to be as great as possible. Next we should see this increase the quality of the translations. A translation is only as good as its source, and having a consistent usage of words can go a long way to helping the translators do better work. The effect of this can be increased by providing a dictionary of important words to the translators so they can be sure to always use the same term in all places. Since we are also working on a guided experience (Campaign), this would also help us give much clearer instructions to the player. An example of confusion here would be if one quest said "Place a chest" and another said "Place the item in the chest". The player needs to read the entire quest caption (probably twice), and can never build up a mental map of our language. This leads to the player spending more mental energy (cognitive load) while playing the game. Changing this to "Build a chest" and being consistent, allows the player to create mental shortcuts, meaning the quest tasks require less effort to understand. Finally, consistency in terminology will help new players, and I don't just mean sub-1 hour playtime players. Factorio is a 'Big Game' and players are encountering new items, entities, concepts, and text for a long time. How many hours did you play before you discovered this helpful trick, or this one? How to change? We could make the vocabulary consistent with what the current player base uses. This option sounds pretty good until I started asking people questions similar to those I asked you at the beginning of the article. Here are another two as a refresher: Where do biters come from? I come in 7 colors, what am I? The only wrong answer is if you said there was only a single right answer. Prepare your rotten tomatoes, Ben is about to say something unpopular. The influx of players that are to be expected from 1.0 give us an interesting option. We could theoretically change the vocabulary of the game to be more consistent, reasonable, and generally more helpful to players. Then, as new players join the community, this new language will slowly replace the old. This would help ease communication between all players; veterans and new addicts alike. Consistency will also help polish the experience to the level that players expect from the game. Who should change it? Before Rseding jumps in with some awesome news, I would ask you to have your say in this Google form. It will be fun to see what you come up with, and I will publish the results in a few weeks.
Removing RTL language translations Wheybags I'm sorry to say that we have removed the RTL language translations (Hebrew and Arabic) in 0.17.20. Until this point we've had a half implementation of RTL languages, where the text is simply flipped when we download it from Crowdin. This 'works' for a decent proportion of things, but not nearly 100%. In order to attain the level of polish we want for the 1.0 release, we would need to spend a lot of time implementing proper support for RTL layouts. This just doesn't make sense for us given our current goals, and the proportion of our player base which uses these languages (less than 0.1%). We decided that instead of completely gutting the translations, we could leave them in for those who enjoy them, but not to offer them in the GUI as defaults. The languages will remain up on Crowdin, and the locale files will still be present in game, but there will be no option in the in-game language options dialog to choose them. If you want to use an RTL language, you will have to manually edit your config file to set your locale. Detailed instructions are available on our forum. What this also means, is that we won't be investigating any bug reports about RTL issues.
Hello, 0.12 will be stable soon, so is a good time to start making you want things from 0.13 right? :)
The Character GUI Twinsen It was 11 months ago when we first mentioned the new Character GUI, in FFF-289. After all that time, it's finally getting ready. Since you can expect to see it released sometime in the next 1 or 2 weeks, we would like to present a quick recap of the features and changes, and some real in-game screenshots. The Character window is now split into 3 tabs. Logisitcs and auto-trash were moved from the central frame into a tab and a new tab called Character was added. Using inventory/stack transfers in the player inventory will transfer the items either to weapons and armor slots or to trash slots depending on the selected tab, regardless of item type. Logistics and auto trash are now merged into 1 panel. Using a double slider you can set an interval. If you have less than the first value, robots will bring more, if you have more than the second value, extra items will be auto-trashed and taken away by the robots. The double pop-up and extra confirm might seem strange, but it's made this way to solve the problem of robots bringing you items before you finished setting up your request. With the merging of requests and auto-trash, we also made it so you can now set an unlimited number of requests, regardless of research. Furthermore, everything is unlocked in one research: unlimited logistic requests, auto trash, and 30 trash slots are all unlocked by the "Logistic robotics" research that is at blue science. Searching now not only searches the recipe GUI, but also the inventory and logistic requests. By popular demand, we also added a switch to quickly turn personal logics on or off. Turning off personal logistics will stop logistic robots from bringing requested items. It will also stop items from automatically being moved to the trash slots. Logistic robots will continue to empty the trash slots. Since the recipe GUI has a new style, we also updated the look of the filter, item, circuit signal, and upgrade selection GUI styles. Some of the other GUIs in the game will have some visual issues due to the mix of old and new styles. My next step will be to fix these issues as soon as the Character GUI is released. Looking back, this GUI took 13 months and 3 programmers (working alternatively) to implement. This is excluding mockups and UX design. It's a long story, but one thing that's obvious is that the GUI scope has grown far beyond what our codebase is capable of. For this reason, we won't be focusing obsessing that much on the GUI in the future. We will finalize the transition of styles, fix obvious issues and low hanging fruits, and try to get everything at a consistent level of quality for 1.0. This new Character GUI and changes will likely affect some mods, especially those relying on logistic technologies, logistic slot related APIs, old style definitions, etc. Thankfully a lot of mods will be unaffected, so we hope it won't be too much disruption. Still, we wanted to give some forewarning.
I've done several optimizations around the game update over the past few game versions but in 0.15 I decided to also look at some of the game GUIs. In particular there are 3 GUIs which tend to take a large amount of time when visible: the production stats, the trains view, and blueprint tooltip previews.
We've been updating, reworking and redesigning many graphics, and the majority of entities have had high resolution for a while now. With 1.0 we're trying to be as "complete" as feasible.
Sound design update Ian One advantage of switching to home working during the COVID-19 crisis is the ability to listen to the game using speakers rather than headphones, and this has proved useful in balancing the relative levels of the game. Val has also been getting to grips with Lua, and this has led him to working on attenuations, which have been proving problematic. For instance, we noticed that sounds such as the radar were getting cut off when you walked away from them, rather than fading out cleanly. I investigated and discovered we had a maximum environment sound limit of 15, by raising this to 50 we have eliminated many of these problems. But then the downside is that there are now more sounds playing and therefore more clutter to mix and balance. Pink squares indicate which sounds are active. Left: limit of 15 nearby sounds; Right: limit of 50 nearby sounds. Rseding has been working through the list of sound design programming tasks, for instance we finally have the sound for the artillery turret rotation integrated into the game (which was featured in FFF-252 quite a while ago). Real in-game footage of the new artillery sounds In other news, we have an updated concept for the transport belts. We listened to feedback from the community that they were still a bit too present and annoying. The idea of the new sounds is that they will drift into the distance a bit more and become unnoticed (until you try to fall asleep). More fun sounds include water splashes, electric and laser beams, more powerful weapons such as the gun turret and vehicle machine gun. And our old robot sounds have come back as additions. If all goes to plan, we will merge the sound changes into master very soon, and once we've done all our pre-release checks, release it to the 0.18 experimental. After that, I plan to spend time on UI sounds, and also balancing the overall levels to get them more in line with other games, which is trickier than normal given the lack of audio middleware. However we have also made some changes to the default sound settings that move us in the right direction.
Hello, A bunch of us will be travelling to Gamescom next week as visitors, if you see anybody wearing a Factorio t-shirt, it might very well be one of us. We don't have a booth or exhibit this year, as we don't want to take any focus away from the development of the game.
